Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-iesg-wgguidelines-00.txt < prev next >

Wrap

Text File | 1993-03-03 | 31.9 KB | 737 lines

Network Working Group Internet Engineering Steering Group INTERNET-DRAFT Erik Huizer SURFnet bv December 1992 IETF Working Group Guidelines and Procedures Status of this Memo, This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. When finalized the draft document will be submitted to the RFC editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author. Abstract The Internet Engineering Task Force (IETF) has the primary responsibility for the development and review of potential Internet Standards from all sources. The IETF is organized into Working Groups (WG). This document describes the guidelines and procedures for formation and operation of an IETF Working Group. It describes the formal relationship between a WG and the Internet Engineering and Steering Group (IESG). The basic duties of a WG chair and an IESG Area Director are defined. The expiration date of this internet draft is 15th July 1993. Contents Introduction Acknowledgements WG formation Charter Review of charter Announcement Birds of a Feather sessions (BOFs) WG meetings WG policies and procedures Document procedures Internet-Drafts RFCs Progression of documents Review of documents Termination of a WG WG chair duties AD duties Security Considerations Authors address References Appendix: Sample Working Group charter Introduction ----------- This document defines guidelines and procedures for Internet Engineering Task Force Working Groups. The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards, commonly known as "the TCP/IP protocol suite". The Internet Standards Process is defined in RFC 1310bis [1]. The primary responsibility for the development and review of potential Internet Standards from all sources is delegated by the Internet Society [2] to the Internet Engineering Task Force (IETF). The goals, structures and procedures of the IETF can be found in it's charter [3]. The Internet Engineering Task Force is chaired by the IETF Chair and managed by its Internet Engineering Steering Group (IESG). The IETF is a large open community of network designers, operators, vendors, and researchers concerned with the Internet and the Internet protocol suite. It is organized around a set of technical areas, each managed by one or two technical Area Directors (AD). In addition to the IETF Chairman, the Area Directors make up the IESG membership. Each Area Director has primary responsibility for one area of Internet engineering activity, and hence for a subset of the IETF Working Groups. At present there are eight areas, though this number may change over time: 1) Applications 2) User Services 3) Internet Services 4) Routing 5) Network Management 6) Operational requirements 7) Security 8) Transport and Services Each Area has an Area Directorate to support the Area Directors a.o. with the review of documents produced in the area. The Area Directorate is formed by the Area Director(s) from senior members of Working Groups (WG) within the area. The work of the IETF is performed by subcommittees known as Working Groups. There are currently more than 60 of these. Working Groups tend to have a narrow focus and a lifetime bounded by completion of a specific task, although there are exceptions. Any member of the Internet community with the time and interest is urged to attend IETF meetings and to participate actively in one or more IETF Working Groups. Participation is by individual technical contributors, rather than formal representatives of organizations. This document defines procedures and guidelines for formation and operation of Working Groups in the IETF. It defines the relations of Working Groups to other bodies within the IETF. The duties of Working Group Chairs and Area Directors with respect to the operation of the Working Group are also defined. The reader is encouraged to read the IETF Charter [3] and the RFC on the Internet Standards process [1]. Familiarity with these documents is essential for an understanding of the procedures and guidelines described in this document. Acknowledgements This document is largely due to the copy-and-paste function of a wordprocessor.Several passages have been taken from the documents cited in the reference section. Three people deserve special mention, as especially large chunks of their documents have been integrated into this one: Vint Cerf [8] from whom I borrowed the description of the IETF. Greg Vaudreuil and Steve Coya [9] provided several paragraphs and detailed feedback. All the errors you'll find are probably mine. Working Group formation ---------------------- IETF Working Groups (WGs) are the primary mechanism for the development of IETF protocols, standards, and recommendations. A Working Group may be established under the direction of an Area Director (AD), or its creation may be initiated by an individual, or group of individuals. Anyone interested in creating an IETF Working Group must consult with the appropriate IETF Area Director under whose direction the Working Group would fall, to confirm that creating a Working Group is appropriate. A Working Group is typically created to address a specific problem or produce a specific deliverable (document, RFC, etc.), and is expected to be short lived in nature. Upon completion of its goals and achievement of its objectives, the Working Group as a unit is terminated. Alternatively, at the discretion of the Area Director and the Working Group chair and membership, the objectives or assignment of the Working Group may be extended by enhancing or adding to the Working Group's statement of objectives When determining if creating a Working Group is appropriate, the Area Director will consider several issues: o Are the issues that the Working Group plans to address important? o Does the work that the WG intends to undertake fit in with the Architecture as understood by the IESG/IAB. o Does the Working Group's activities overlap with those of another Working Group? If so, it may still be appropriate to create another Working Group, but this question must be considered carefully by the Area Director as subdividing efforts often dilutes the available technical expertise. o Are there several people clearly interested in the Working Group's topic and willing to expend the effort to produce a result (such as an RFC)? Working Groups require considerable manpower: a chairman is needed to run meetings, an editor to edit authors' submissions, and authors to actually write text. IETF experience suggests that these roles typically cannot all be handled by one person, four or five active members are typically required. If the necessary manpower is lacking, the person interested in creating the Working Group might consider actually writing the RFC alone and submitting it for review, rather than attempting to create a Working Group. Considering the above criterion, the Area Director will decide whether to pursue the formation of the group through the chartering process. Charter The formation of a Working Group requires an approved statement of direction or objectives along with establishing the administrative aspects of the Working Group which involves identifying the WG Chair or co-Chairs, the WG secretary (which can also be the WG chair), and the creation of a mailing list. This information is included in the Working Group Charter. The content of the charter document is negotiated between a prospective Working Group chair and the relevant Area Director. The work statement must explain the general purpose of the group, define its technical scope, enumerate a set of goals and milestones together with time frames for their completion, and document various administrative points. When both the prospective Working Group chair and the Area Director are satisfied with the charter text, it becomes the basis for forming a Working Group. The charter document may be similarly renegotiated or modified at any time during the course of the Working Group's effort to reflect the changing goals of the group. Each charter consists of five sections. These sections include information about the Working Group (the name, the chairmen, objectives, goals and milestones, and the mailing lists. The goals and milestones are part of the IETF tracking system, and are designed to allow a degree of project management and support. They may change periodically to reflect the current status or organization of the Working Group. 1. Working Group Name: A Working Group name should be reasonable descriptive or identifiable. Additionally, the group needs to define an 8 character ASCII acronym to reference the group in the IETF directories, mailing lists, and general documents. 2. Working Group Chair(s): The Working Group may have one or two chair(s) to perform the administrative functions of the group. It is strongly suggested that these individuals have Internet mail addresses. 3. Working Group Description: In one to two paragraphs, the focus and intent of the group should be set forth. By reading this section alone, an individual should be able to decide whether this group is relevant to their work. Recognizing the importance of security and network management in the Internet Architecture, this description of the work of the group must specifically address the impact in terms of security and management. 4. Goals and Milestones: The Working Group should, after the first meeting, be able to establish a timetable for work. While this may change over time, the list of milestones and dates facilitate the Area Director's tracking of Working Group progress and status, and it is indispensable to potential participants to be able to identify the critical moments for input. Milestones should consist of deliverables that can be qualified as such, e.g. 'Internet-draft finished' is fine, but 'discuss via E-mail' is not. This milestone list is expected to be updated periodically. Updated milestones should be submitted along with meeting minutes to the IETF Secretariat (iesg-secretary@cnri.reston.va.us). 5. Mailing Lists: Most of the work of an IETF Working Group is conducted on Internet Mail exploder lists. It is required that an IETF Working Group have a general discussion list. An individual needs to be designated as the list service postmaster, usually through the list-request alias mechanism. A message archive should be maintained in a public place which can be accessed via FTP. The IETF-archive@cnri.reston.va.us should be included on the mailing list. Note: It is strongly suggested that the mailing list be on an connected IP host, to facilitate use of the SMTP expansion command (EXPN) and to allow access via FTP to the mail archives. If this is not possible, the message archive and membership of the list must be made available to those who make such a request by sending a message to the list-request alias. The list maintainer or archiver need not be the Working Group chairman or secretary, but may be a member of the Working Group itself. An example of a WG charter can be found in appendix A. Charter Review Once the Area Director has approved the Working Group charter, the charter is submitted to the Internet Engineering and Steering Group and Internet Architecture Board for review and approval. The IESG will primarily consider if : - the WG has no overlap with WGs in other areas; - there is sufficient expertise in the IETF to review the results of the WG; The Internet Architecture Board (IAB) will review the charter of the proposed WG to see whether the proposed work is relevant to the overall architecture of the Internet Protocol Suite. The approved charter is submitted to the IESG secretary (currently at CNRI) who records and enters the information into the IETF tracking database and returns the charter in form formatted by the database. Using this reformatted charter, the Working Group is announced by the IESG Secretary to the IETF mailing list. Birds of a Feather (BOF) For an individual, or small group of individuals, it is often not clear if the issue(s) at hand merit the formation of a WG. To alleviate this problem the IETF offers the possibility of a Birds of a Feather (BOF) session. A BOF is a session at an IETF where a brainstorm type of discussion is held on a subject proposed by the chair(s) of the BOF. Any individual (or group of individuals) can request permission to hold a BOF on a certain subject. The request has to be filed with the relevant Area Director. The person who requests the BOF is usually appointed as chair of the BOF. The chair of the BOF is also responsible for providing a report on the outcome of the BOF. Usually the outcome of a BOF will be one of the following: - There was enough interest in the subject to warrant the formation of a WG; - The discussion came to a fruitful conclusion, the results will be written down and published as a RFC. There is no need to establish a WG; - There was not enough interest in the subject to warrant the formation of a WG. There is an increasing demand for BOF sessions at IETF meetings. Therefore as a rule it is not allowed to have multiple BOF sessions on the same subject at IETF meetings. Working Group Meetings --------------------- The Working Group is expected to meet periodically to discuss and review task status and progress, and to direct future activities. It is expected, but not required that every Working Group meet at the trimester IETF plenary sessions. Additionally, interim meetings are encouraged by telephone conference, video teleconference, or by actual face to face meetings. Meetings should be publicized as widely as possible, by announcing their time and location on the Working Group mailing list etc. When a meeting is held outside of an IETF session, the WG meeting should be announced to the IETF mailing list too. All Working Group sessions (also the ones held outside of the IETF sessions) should be reported by making minutes available. These minutes should include the agenda for the meeting, an account of the discussion including any decisions made, and a list of attendees. The Working Group chair is responsible for insuring that meeting minutes are written and distributed, though the actual task may be performed by the Working Group secretary or someone designated by the Working Group chair. The minutes submitted in ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories. If a WG wants to meet at an IETF meeting, it has to apply for a timeslot. In order to be efficient with allocation of sparse time- slots, and in order to coordinate as well as possible WGs that require more or less the same subset of experts (such that these experts do not waste time due to gaps between meetings), the WG chair needs to apply for a meeting at an IETF to the secretariat, as soon as the first announcement of that IETF meeting is made by the IETF secretariat to the wg-chairs list. The application for a WG meeting at an IETF meeting needs to be made to the IETF secretariat, and it needs to contain: - the amount of time requested; - the rough outline of the agenda that is expected to be covered; - the estimated number of people that will attend the WG meeting. The secretariat will form a draft agenda and distribute it among the wg-chairs for approval. Alternatively some Area Directors may want to coordinate WG meetings in their area and request that timeslots be coordinated through them. After receiving all requests for timeslots by WGs in the area, the Area Director(s) form a draft agenda for their area, which will be send to the WG chairs of the area. After approval it will be send to the IETF secretariat. The secretariat allots the timeslots on basis of the agenda made by the Area Director(s). If the proposed agenda for an area does not fit into the IETF meeting agenda, the IETF secretariat will adjust it to fit, after consulting the Area Director(s) and the relevant chairs. WG policies and procedures ------------------------- All Working Group actions should be public, and wide participation encouraged. Announcements of meeting dates and time must be sent to the Working Group mailing list and to mdavies@cnri.reston.va.us a reasonable time before the meeting. All Working Groups are autonomous, and each may have their own policies and procedures with respect to meeting participation, reaching closure, etc. Generally, acceptance or agreement is achieved via Working Group consensus, though some Working Groups may decide that a simple majority, significant majority (two thirds) or unanimous agreement is required. A number of procedural questions and issues have risen over time, and it is the function of the Working Group chair to manage this process, keeping in mind that the overall purpose of the group is to make progress towards realizing the Working Group's goals and objectives. There are no hard and fast rules on organizing or conducting Working Group activities, but a set of guidelines and practices have evolved over time that have proven successful. Some of these "topics" are listed here. Note that the choice of options is typically determined by the Working Group members and the chairman. 1. The chair is encouraged to publish a draft agenda well in advance of the actual meeting. The agenda needs to contain at least: - items for discussion; - estimated time necessary per item; - clear indication of what documents the participants will need to read before the meeting in order to be well prepared. The documents should be publicly available (preferably as Internet- drafts, see next section) and the "where and how to get them" should be indicated. 2. All relevant documents for a meeting (including the final agenda) should be published and available at least two weeks before the meeting starts. 3. It is strongly suggested that the WG chair creates an anonymous FTP directory specially for the upcoming meeting. All relevant documents (including the final agenda and the minutes of the last meeting) should be placed in this directory. This has the advantage that all participants can just ftp all files in this directory and thus make sure they have all relevant documents. 4. After a period of open meetings, the Working Group chair may hold executive (closed) meetings of the Working Group consisting of the authors of a particular document and any serious reviewers. This is often necessary to make forward progress preparing a final document. All work conducted in executive session must be made available for review by all Working Group members. 5. It is acceptable to have restricted participation (not attendance!) at IETF Working Group meetings for the purpose of achieving progress. The Working Group chairman usually has the authority to refuse to grant the floor to any unprepared individual. 6. Many Working Group participants hold that mailing list discussion is the place to resolve issues and make decisions, while others maintain that such should be accomplished only at IETF meetings. Resolution and acceptance within the Working Group is resolved by the Working Group. 7. Consensus can be determined by balloting, humming, or any other means the WG will agree on (by consensus of course). 8. Repeated discussions on the same issues over E-mail can be avoided if the chair makes sure that after a discussion has come to a conclusion, the main arguments in the discussion (and the outcome) are summarized and archived. It is also good practice to note important decisions/consensus reached by E-mail in the minutes of the next 'live' meeting. Document procedures ------------------- Internet Drafts The IETF provides the Internet Drafts directories are provided to the Working Groups as a resource to post and disseminate early copies of any and all documents of the Working Group. This common repository is available to all interested persons to facilitate wide review and comment. It is encouraged that draft documents be posted as soon as they become reasonably stable. It is stressed here that Internet Drafts are drafts and have no official status whatsoever. Request For Comments (RFC) The work of an IETF Working Group usually results in the publication of one or more Request For Comments Documents (RFCs) [4]. This series of documents are the journal of record for the internet community. A document can be written by an individual in the Working Group or by the group as a whole with a designated editor. The designated author need not be the group chair(s). Note: The reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards! For a description on the various subseries of RFCs the reader is referred to [1,5,6,7]. Submission of documents When a WG decides that a working document is ready for progression to RFC, the following has to be done: - The relevant document as approved by the WG has to be in the Internet-Drafts directory; - The relevant document has to be formatted according to RFC-rules (see RFC-1111 [4]). - The WG chair sends an E-mail, containing the reference to the document, and the request that it be progressed as an (Informational, experimental, prototype or proposed STD) RFC to the Area Director(s), with a cc: to the IESG Secretary. The Area Director(s) will acknowledge receipt of the E-mail. From then onwards the progressing of the document is the responsibility of the IESG. Review of documents In case the submission is intended for Informational only no review is necessary. However if the WG or the RFC editor thinks that a review is appropriate the AD can be asked to provide a review. In case of submission as an Experimental, Prototype or Standards RFC, the document will always be reviewed by the IESG. The review can either be done by the AD and other IESG members or by independent (i.e. not having been part of the WG in question) reviewers from the Area Directorate. Before making a final decision on a document, the IESG will issue a "last call" to the IETF mailing list. This "last call" will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF within a period of two weeks. The review will lead to one of three possible conclusions: 1- The document is accepted as is; This fact will be announced by the IESG to the IETF mailing list and to the RFC Editor. Publication is then further handled between the RFC editor and the author(s). 2- One or more changes regarding content are suggested to the author(s)/WG. Once the author(s)/WG has made these changes or has argued to the satisfaction of the reviewers why the change(s) is/are not necessary, the document will be accepted for publication as under point 1 above. 3- The document is rejected; This will need strong and good argumentation from the reviewers. The whole process is structured such that this situation is not likely to arise for documents coming from a Working Group. After all the intents of the document would already have been described in the WG charter, and this has already been reviewed at the outstart of the WG. If any individual or group of individuals feels that the review treatment has been unfair, there is the possibility to make a procedural complaint. The mechanism for procedural complaints is described in the Charter of the IETF [3]. Termination of a WG ------------------- Working Groups are typically chartered to accomplish a specific task. After that task is complete, the group will be disbanded. If after a meeting a few times, it becomes evident that the group is unable to complete the work outlined in the charter, the group, in consultation with its Area Director can either 1) recharter to refocus on a smaller task, 2) choose new chair(s), or 3) disband. In those situations where the Working Group chairperson and the Area Director disagree about the steps required to refocus the group or the need to disband the group, the IESG will make a determination with input from the Area Director and the Working Group chair(s). Major changes will need a review from the IAB. WG chair duties -------------- The Working Group chair(s) have wide discretion in the conduct of business. The WG chair has to make sure that the WG operates in a reasonably efficient and effective way towards reaching the goals and results described in the WG charter. This very general description encompasses at the very least the following detailed tasks: - Moderate the WG distribution list; The chair makes sure that the discussions on this list are relevant and that they converge. The chair makes sure that discussions on the list are summarized and the outcome is well documented (to avoid repeats). - Organize, prepare and chair face-to-face meetings; The chair plans and announces the meeting well in advance (see section on WG meetings for exact procedures). The chair makes sure that relevant documents and the final agenda are ready at least 2 weeks in advance of the meeting. The Chair makes sure minutes are taken, and that an attendance list is circulated. It is strongly suggested that the WG chair creates an anonymous FTP directory specially for the upcoming meeting. All relevant documents should be placed in this directory. - Communicate results of meeting; The chair makes sure that minutes of the meeting are taken. After screening the minutes the final version will be send to the Area Director(s) and the IETF secretariat, in time for publication in the IETF proceedings. The WG chair provides the Area Directors with a very short report (preferably via E-mail) on the meeting directly after the meeting took place. These reports will be used for the Area Report as presented in the proceedings of each IETF meeting. - Distribute the work; Of course each WG will contain a lot of participants that may not be able to (or want to) do any work at all. Most of the time the work is done by a few experts. It is the tasks of the chair to motivate enough experts to allow for a fair distribution of the workload. - Progress documents. The chair will make sure that authors of WG documents incorporate changes as discussed by the WG. Once a document is approved by the WG the chair reports to the Area Director(s) and the IESG secretary. The chair indicates (per E-mail) which document has been approved, and asks the IESG to review it for publication as an RFC (specify experimental, proposed STD etc.). The Area Director will acknowledge the receipt of the E-mail, and from then on the action is on the IESG. See the section on review of documents for possible further involvement of the chair in document progressing. Area Director duties ------------------- The Area Directors are responsible for a coherent, coordinated and architecturally consistent output from the Working Groups in their area as a contribution to the overall results of the IETF. This very general description encompasses at the very least the following detailed tasks related to the Working Groups: - Coordination of WGs; The Area Director(s) coordinate the work done by the various WGs within (and sometimes even outside) the relevant Area. The Director(s) try to coordinate meetings in such a way that experts can attend the relevant meetings with a minimum of overlap and gaps between meetings. (See section on WG meetings for details) - Reporting; The Area Director(s) report on the progress in the Area to the IETF. - Reviewing; The Area Directors appoint independent reviewers for document reviewing. The Area Director(s) track the progress of documents from the Area through the IESG review process, and report back on this to the WG Chair(s). - Progress tracking; The Area Directors track and manage the progress of the various WGs with the aid of a regular status report generated by the IESG secretary. The Area Directors forward this regular status reports on documents and milestones made by the IESG Secretary to the WG chairs. This in turn helps the chairs to manage their WGs. - Area Directorate; The Area Director chairs the Area Directorate. He is responsible for regular meetings of the directorate. Security Considerations ---------------------- Security issues are not addressed in this memo. References ---------- [1] RFC1310bis [2] Charter Internet Society [3] New charter IETF [4] RFC 1111 Request for Comments on Request for Comments, J. Postel, August 1990. [5] RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March 1990 [6] RFC 1311 Introduction to the Standards Notes, ed. J. Postel, March 1992. [7] RFC 1360 IAB Official Protocol Standards, ed. J. Postel, Sept. 1992. [8] RFC 1160, The Internet Activities Board, V.Cerf, may 1990 (This should be OBE by [3] by the time this gets published) [9] Guidelines to Working Group Chair(s), S. Coya, IESG distribution only. Authors address --------------- Erik Huizer SURFnet bv P.O. Box 19035 3501 DA Utrecht The Netherlands Phone: +31 30 310290 Fax: +31 30 340903 Email: Erik Huizer@SURFnet.nl The expiration date of this Internet draft is 15th July 1993 Appendix: Sample Working Group charter ------------------------------------ MIME-MHS Interworking (mimemhs) Charter Chair(s): Steve Thompson <sjt@gateway.ssw.com> OSI Integration Area Director(s) Erik Huizer <huizer@surfnet.nl> Dave Piscitello <dave@sabre.bellcore.com> Mailing lists: General Discussion:mime-mhs@surfnet.nl To Subscribe: mime-mhs-request@surfnet.nl Archive: Description of Working Group: MIME, (Multipurpose Internet Mail Extensions) currently an Internet Draft, is expected to become an Internet Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. With the introduction of MIME as a Proposed Standard it is now possible to define mappings between RFC-822 content-types and X.400 body parts. The MIME-MHS Interworking Working Group is chartered to develop these mappings, providing an emphasis on both interworking between Internet and MHS mail environments and also on tunneling through these environments. These mappings will be made in the context of an RFC-1148bis environment. Goals and Milestones: Jan 92 Post an Internet Draft describing MIME-MHS Interworking. Jan 92 Post an Internet Draft describing the ``core'' set of Registered conversions for bodyparts. Jul 92 Submit a completed document to the IESG describing MIME-MHS Interworking as a Proposed Standard. Jul 92 Submit the ``core'' bodyparts document to the IESG as a Proposed Standard.